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With the growth of the Internet, business-to- 
business procurement and other processes 
are being moved to the World Wide Web, for 
increased efficiency and reach. Procurement 
systems from different vendors use various 
protocols, and additional protocols are being 
defined by several industry consortia. As a 
consequence, suppliers are faced with the 
difficult task of supporting a large number 
of protocols in order to interoperate with 
various procurement systems and private 
marketplaces. In this paper, we outline the 
connectivity requirements for suppliers and 
private marketplaces, and we describe how 
suppliers and marketplaces based on IBM’s 
WebSphere® Commerce Business Edition and 
WebSphere Commerce Suite, Marketplace 
Edition can interoperate with diverse 
procurement systems and electronic 
marketplaces. We first describe simple 
connectivity based on punchout processes 
for fixed and contract-based pricing. We 
then describe how asynchronous processes, 
such as requests for quote, auctions, 
and exchanges can be distributed for 
interoperability across suppliers and 
marketplaces. Finally, we describe B2B/M2M 
Protocol Exchange, a prototype we have 
implemented that maps between different, but 
analogous, protocols used in procurement 
systems, and thus alleviates some of the 
interoperability difficulties. 
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J. T. Rayfield 
H. H. Shaikh 

T. K. Sreeram 

With the rapid growth of the Internet, organizations 
are increasingly using the Web to conduct business 
with greater speed, reach, and efficiency. This trans¬ 
formation is especially prevalent in business-to-busi- 
ness (B2B) commerce and trade. Many of the For¬ 
tune 500 companies have adopted e-procurement 
systems such as Ariba, Commerce One, and mySAP. 
Many others participate as buyers in e-marketplaces 
such as Commerce One MarketSet, Ariba Hosted 
Market Place, and IBM’s WebSphere* Commerce 
Suite, Marketplace Edition (WCS MPE, or MPE for 
short), among others. 

Figure 1 illustrates the environment for B2B procure¬ 
ment on the Web. B2B buyers have diverse procure¬ 
ment systems, such as those offered by Ariba, Com¬ 
merce One, and SAP, among others. Each of these 
procurement systems uses different B2B protocols for 
interaction with seller systems. Many of these pro¬ 
tocols are proprietary and specific to the procure¬ 
ment system. For example, as illustrated in Figure 
1, Ariba uses the punchout process between the 
Ariba Order Request Management System (ORMS) 
and seller systems using their “Commerce XML” 
(cXML, or Commerce Extensible Markup Language) 
specification for the messagesCommerce One uses 
xCBL 2 as the format of messages; mySAP uses the 
“Open Catalog Interface” (oci) (for a process sim¬ 
ilar to punchout) between buyer and seller systems. 3 
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Figure 1 Business-to-business procurement environment 
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Many other protocols for B2B processes, many pro¬ 
prietary to procurement and other systems, and oth¬ 
ers customized for specific partners, are being de¬ 
fined and implemented. In addition to the pro¬ 
curement systems, which typically reside within the 
firewall of the buying organizations, marketplaces 
are being set up on the Internet through which buy¬ 
ers can access a large number of suppliers, typically 
for specific industry segments. Many of these mar¬ 
ketplaces use the same or similar technology to con¬ 
nect to procurement and supplier systems, and offer 
buyers at small and medium-sized businesses access 
to suppliers. 

Meanwhile, standards bodies are defining protocols 
and message formats for B2B processes. One of the 
early processes was that defined by the Open Buy¬ 
ing on the Internet (OBl) consortium, 4 a precursor 
of the punchout process. The RosettaNet consor¬ 
tium used OBI as a starting point and defined Part¬ 
ner Interchange Processes (PlPs), 5 including both 
flows and XML-based 6 message formats for interac¬ 
tions between partners. The electronic business XML 


(ebXML) framework, sponsored by UN/CEFACT (Unit¬ 
ed Nations Center for the Facilitation of Procedures 
and Practices for Administration, Commerce, and 
Transport) and OASIS (Organization for the Ad¬ 
vancement of Structured Information Standards) in¬ 
cludes a messaging service, 7 a Collaborative-Proto¬ 
col Agreement (CPA) 8 specification, and a Business 
Processes Specification Schema, 9 all used for en¬ 
abling the interaction between business processes. 
The Web services approach 10 defines both a mes¬ 
saging and a remote procedure call mechanism us¬ 
ing SOAP (Simple Object Access Protocol); 11 on top 
of SOAP, the WSDL (Web Services Description Lan¬ 
guage) 12 defines a Common Object Request Bro¬ 
ker Architecture** (CORBA**) 13 IDL (interface def¬ 
inition language)-like interface for Web-based B2B 
remote procedure calls; and the UDDI (Universal De¬ 
scription, Discovery, and Integration) consortium has 
defined a directory mechanism for registering and 
locating businesses on the Web, 14,15 with an optional 
WSDL interface specification. The Open Application 
Group (oag) 16 has defined Business Object Doc¬ 
uments (BODs) for the content of B2B messages. 
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Figure 2 B2B connectivity requirements 
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Some of these originally disparate efforts are now 
coming together. For example, the RosettaNet con¬ 
sortium has announced that they will move to the 
ebXML messaging protocol, and OAG has announced 
that they will support ebXML. In spite of these efforts, 
however, the number of B2B protocols continues to 
grow. 

This proliferation of B2B protocols gives rise to sev¬ 
eral connectivity requirements and problems, as il¬ 
lustrated in Figure 2. First, from a supplier’s point 
of view (box A in Figure 2), suppliers need to con¬ 
nect to the many customer procurement systems and 
private marketplaces, using various B2B protocols. 
Second, private marketplaces (and, over time, pro¬ 
curement systems as well) need to connect to pro¬ 
curement systems (box B in Figure 2), using differ¬ 
ent B2B protocols. Third (box C in Figure 2), private 
marketplaces need to connect to suppliers where the 
suppliers may support different B2B protocols. Fourth 
(box D in Figure 2), private marketplaces need to 
connect to each other, in order to access suppliers 
connected to other marketplaces, or to access ser¬ 
vices offered at other marketplaces. 


In this paper, we discuss the connectivity require¬ 
ments for suppliers and private marketplaces, and 
describe how suppliers and marketplaces relying on 
IBM’s WebSphere Commerce Business Edition 
(wcbe) and WebSphere Commerce Suite, Market¬ 
place Edition (WCS mpe) can interoperate within the 
environment for B2B procurement. The next section 
describes simple B2B connectivity using punchout 
processes as supported by WCBE. In the section that 
follows, we discuss marketplace connectivity for 
emerging asynchronous processes and distributed 
trading mechanisms, as supported by WCS MPE. In 
the section “Connectivity using a B2B protocol ex¬ 
change,” we show that many of these protocols can 
be mapped to each other, thus allowing procurement 
systems and suppliers to use possibly different pro¬ 
tocols. The last section contains ideas for future work 
and concluding remarks. 

Simple B2B connectivity using punchout 

In this section we focus on two of the B2B connec¬ 
tivity problems mentioned above and illustrated in 
Figure 2. First, we discuss the supplier connectivity 
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problem and present a solution based on IBM’s Web¬ 
Sphere Commerce Business Edition 17 (wcbe) for 
connectivity of suppliers to diverse procurement sys¬ 
tems. Second, we discuss marketplace connectivity 
and present a solution based on IBM’s WebSphere 
Commerce Suite, Marketplace Edition 18 (wcs mpe) 
for connectivity of marketplaces to diverse procure¬ 
ment systems and diverse supplier systems. 

Most procurement systems and private marketplaces 
support the notion of punchout (albeit using some¬ 
times a different term, such as RoundTrip, used by 
Commerce One). A buyer at a procurement system 
or marketplace selects a remote supplier, the buyer 
is automatically logged on to the supplier catalog 
server and presented with a catalog customized for 
his or her organization, with prenegotiated prices. 
The buyer shops at the site, the items selected for 
purchase being stored in a shopping cart. On check¬ 
out the shopping cart contents are sent back to the 
buyer’s procurement system for approval. The pro¬ 
curement system provides workflow for approvals 
and, on approval, a purchase order is sent from the 
procurement system to the supplier. Additional mes¬ 
sages may be exchanged between the supplier and 
the procurement system, such as shipping notices and 
invoices. (Details of the punchout flow are provided 
later.) By having punchout capability, suppliers and 
marketplaces can interoperate with procurement sys¬ 
tems or marketplaces, with significant benefits to 
both suppliers and buyers. 

IBM WCBE version 5.4 is a solution for the business- 
to-consumer trade, whereas WCS MPE version 4.2 sup¬ 
ports the private trading exchange customers. Cus¬ 
tomers can connect to the WCBE Web site, browse 
through the catalog, and place orders. In the case 
of WCS MPE, customers have the benefit of working 
with various trading mechanisms such as RFQs, auc¬ 
tions, reverse auctions, and exchanges. It is especially 
useful, given the emerging trends in the industry, that 
the WebSphere Commerce products have punchout 
capability and be able to interoperate with buyers’ 
procurement systems and marketplaces. 

Although WCS MPE supports aggregation of suppli¬ 
ers’ catalogs, certain suppliers may have enormous 
catalogs and their systems may include complex con¬ 
figuration tools; often it is not feasible to offload sup¬ 
plier catalogs into external marketplaces. Thus sup¬ 
pliers often have their supply-side Web sites enabled 
for punchout, and expect WCS MPE to initiate punch¬ 
out to the supplier Web site. 


Catalog aggregation in the current WCS MPE prod¬ 
uct is done using the WebSphere Catalog Manager 
(wcm) product. WCM supports loading of catalog 
data into an electronic marketplace (eMP) database, 
transforming catalog data from ASCII, spreadsheet, 
and XML formats into a canonical XML format, and 
extracting catalog data from any relational database. 
More enhancements to support industrial catalogs 
are planned for future versions of WCM. 

Many large corporations have relatively independent 
subsidiaries and are classic examples of customers 
that require support for both receiving punchout re¬ 
quests and initiating punchout requests. Such cor¬ 
porations often have aggregated supplier catalogs 
across their subsidiaries so that their customers see 
a unified company-wide catalog and require support 
for receiving punchout requests from the buyers’ pro¬ 
curement systems to the aggregated catalog. They 
also require punchout initiation functionality to con¬ 
nect from their aggregated-catalog server to individ¬ 
ual catalogs supported by their subsidiaries. 

Punchout from procurement systems to WCBE and 

WCS MPE. IBM Commerce Integrator is a generic 
framework that enables WCBE 5.1 and WCS mpe 4.2 
to handle business-to-business transactions using in¬ 
dustry standard protocols. It offers customers the op¬ 
portunity to integrate their systems with the procure¬ 
ment system’s own network of high-volume buyers. 
Commerce Integrator provides an integrated, scal¬ 
able system that enables suppliers with WCBE to par¬ 
ticipate as a supplier in the procurement system’s 
marketplace, to increase sales, and to enhance their 
business-to-business presence on the Web. Specif¬ 
ically: 

• Suppliers maintain a single catalog within WCBE 
and use that catalog to enable their own Web pres¬ 
ence as well as to participate in the procurement 
system’s network. 

• Suppliers can take advantage of WCBE connectivity 
to supply chain management systems, retail bus¬ 
iness systems, and order management backend sys¬ 
tems to automatically flow orders from the buy¬ 
er’s procurement system. 

• Suppliers can take advantage of the updated busi¬ 
ness-to-business features of the WCBE product for 
using and maintaining information about buyer or¬ 
ganizations, buyer-specific catalogs and price lists, 
and contract pricing. 

Figure 3 illustrates a high-level view of a typical 
punchout flow in which WCBE interoperates with an 


IBM SYSTEMS JOURNAL, VOL 41, NO 2, 2002 


DIAS ET AL. 275 


Figure 3 Typical punchout flow using WCBE and 
Commerce Integrator 


2 LOGIN TO 
SUPPLIER 


1 LOGIN AND 
SELECT 
CATALOG 




6 RECEIVE 
QUOTE 


7 ORDER 
APPROVED 




3 LOGIN RESPONSE 


A QunDDIMn QPQQIflM 


5 GET QUOTE 


8 FINAL ORDER 



e-procurement system, which includes the following 

steps. 

1. An agent in the buyer organization logs on to the 
procurement system using the user ID (identifi¬ 
er) and password, and then selects an external cat¬ 
alog. The procurement system authenticates the 
buyer agent. 

2. The procurement system constructs a request to 
access the external supplier catalog using a user 
ID and other buyer organization credentials. 

3. The Member Subsystem of Commerce Integra¬ 
tor authenticates the buyer agent against the 
buyer organization data stored in the WCBE da¬ 
tabase. If successful, the buyer agent is presented 
with a catalog customized for the buyer organi¬ 
zation. 

4. The buyer agent browses the catalog in the WCBE 
database while a shopping cart is created. On 
checkout, the shopping cart is submitted to WCBE, 
and a quote is recorded in the database. 

5. Commerce Integrator picks up the quote from 
WCBE. 

6. Commerce Integrator sends the quote to the 
buyer in the format required by the buyer’s pro¬ 
curement system. An authorized agent for the 
buyer is prompted for acceptance of the quote. 

7. The authorized agent approves the quote. An or¬ 
der from the procurement system is sent to Com¬ 
merce Integrator. 

8. Commerce Integrator forwards the order to 
WCBE. 


Further messages, such as advance shipment notices 
and invoices (not shown in Figure 3) are sent from 
WCBE to the procurement system. 

Although the punchout flow is similar for most pro¬ 
curement systems, the message format is different 
for different procurement systems. For example, 
Ariba uses cXML messages, 1 mySAP uses HTML 
name-value pairs, 3 Metiom uses the OBI EDI (elec¬ 
tronic data interface) message formats, 4 and Com¬ 
merce One uses xCBL message formats. 2 There are 
some differences between the flows, as outlined in 
the section on the B2B protocol exchange. To han¬ 
dle these differences, Commerce Integrator includes 
some protocol-specific functions, in addition to func¬ 
tions common to all protocols. As shown in Figure 
4, incoming messages are handled by a common serv¬ 
let, which identifies the protocol and calls protocol- 
specific functions that map the message to a com¬ 
mon internal format. Then WCBE commands, shared 
by all punchout protocols, are invoked. Responses 
are converted from the common format into proto- 
col-specific formats by Commerce Integrator. 

Figure 4 also shows a B2B gateway. The function of 
the B2B gateway is to provide a means of connecting 
remote trading partners over the Internet, each us¬ 
ing its protocol of choice. Clearly, this functionality 
facilitates the integration of interenterprise business 
processes. Although the B2B gateway may support 
additional functions, such as business process man¬ 
agement, audit trails, and intraenterprise connec¬ 
tivity, we do not elaborate further on these functions. 

The protocol associated with an incoming message 
is identified by the URL (uniform resource locator) 
to which the request is sent. The use of a single serv¬ 
let for all requests should have no negative perfor¬ 
mance impact, because the servlet engine launches 
a new thread for each request. Performance bottle¬ 
necks would only be caused by undue contention for 
shared resources. Were such contention present, it 
would impact multiple servlets in the same manner 
as a single servlet. Because the servlet is merely the 
entry point for requests that quickly fan out to dif¬ 
ferent parts of the server, it is unlikely that the deg¬ 
radation of reliability from the use of a single serv¬ 
let would be significant. 

There are two scenarios of interest: one in which 
there is no separate B2B gateway, and one in which 
there is a gateway present. When there is no B2B gate¬ 
way, protocol-specific requests are sent to Commerce 
Integrator, and appropriate commands are invoked. 
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Figure 4 WCBE Commerce Integrator architecture 



If a B2B gateway is present, the incoming requests 
are mapped into a common canonical format, and 
then Commerce Integrator invokes appropriate 
WCBE commands. Thus, there is a synergistic rela¬ 
tion between WCBE/Commerce Integrator and the 
gateway. 

Punchout from WCBE and WCS MPE to external 
suppliers. A traditional electronic marketplace (eMP) 
or a private trading exchange (ptx), such as 
IBM WCS MPE 4.2, provides various trading mecha¬ 
nisms: RFQs, contract-based buying, fixed-price buy¬ 
ing, auctions, exchange, etc. It also provides support 
for aggregated catalogs. Both buyers and sellers be¬ 
gin by using the catalog to select a product to buy 
or to sell. When sellers offer products for sale, they 
specify the method of purchase to be used: RFQ, con¬ 
tracted price, fixed price, auction, or exchange. Buy¬ 
ers must purchase products using the method spec¬ 
ified by the seller (with the exception of RFQ, which 
they can initiate). 

Aggregating the catalog at the eMP site offers advan¬ 
tages including: 

• It makes possible a parametric search across sup¬ 
pliers. 

• It enables small businesses, which do not have the 
infrastructure to host catalogs, to engage in e-com¬ 
merce. 

Aggregating catalogs, however, has its own limita¬ 
tions, including: 


• It does not preserve each supplier’s unique brand 
and Web site design (it requires direct links to the 
supplier’s Web pages). 

• It supports only static content rather than promot¬ 
ing dynamic, up-to-date information. 

• It provides limited support for suppliers with very 
large catalogs. 

• It provides no support for product configurators 
(needed for complex products). 

• It provides limited support for suppliers with fast 
changing catalogs or pricing. 

Thus, in situations where there is a need for product 
configurators, or if the catalog contains fast chang¬ 
ing products and prices, the suppliers have to main¬ 
tain catalogs at their own sites and not aggregate the 
catalog onto an eMP. In the common eMP approach, 
a buyer has access to only the sellers who partici¬ 
pate in the marketplace with which the buyer is reg¬ 
istered. Similarly, a seller cannot sell goods and ser¬ 
vices in a marketplace different from the one with 
which the seller is registered. We describe next a 
mechanism called punchout in which a buyer in a 
private marketplace can “punch out” to a remote 
supplier to buy fixed-price and contract price offer¬ 
ings. 

Figure 5 shows the flow for setting up a punchout 
process from a procurement system (or marketplace) 
to a supplier site, for example, a WCBE site. Remote 
suppliers are listed at the procurement system. They 
may provide their entire catalog remotely using 
punchout. Alternatively, a supplier may provide a 
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Figure 5 Typical punchout request flow 
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local catalog at the procurement site, with links for spe¬ 
cific functions or details. For example, a supplier may 
use punchout for system configuration, or for parts 
of the supplier catalog that may change frequently. 
As shown in Figure 5, after selecting a remote sup¬ 
plier for initial or further shopping (1), a login re¬ 
quest (2) is sent to the remote supplier as an xml 
document, encapsulating the user and organization 
credentials, as well as a URL for postback to the 
procurement system (used at step 7, below). The re¬ 
mote supplier authenticates this request and returns 
a URL (3) with embedded user information. The 
client’s browser is redirected (4) to this URL, allow¬ 
ing the buyer to directly shop (5) at that remote site 
using the appropriate catalog for the buyer’s orga¬ 
nization. At the end of the shopping session, a 
quote representing the shopping cart is sent back 
to the client (6) and posted back to the procure¬ 
ment system (7) at the postback URL referred to 
above. 

After the purchase request (in XML format) is re¬ 
ceived back at the procurement system (7), it is 
parsed and added to the buyer’s requisition. (The 
buyer may punchout to multiple suppliers and add 
the contents of those shopping carts to his or her 
requisition.) The buyer then submits the requisition 
for approval. After submission, the buyer can then 
view the submitted requisition and its status, and 
modify the requisition, if so desired. 

Subsequently, the approver views the submitted req¬ 
uisitions, and optionally may punchout to the sup¬ 
plier to view details of the requisition. The approver 


can modify the requisition, if so desired. If the ap¬ 
prover rejects the requisition, the status is so indi¬ 
cated, and can be viewed by the buyer; if the req¬ 
uisition is approved, it is converted into one or more 
purchase orders (POs), and sent to the supplier(s). 
The PO is sent as an XML document, in the format 
required by the supplier. If the remote supplier’s sys¬ 
tem is based on WCBE, the PO is formatted in a com¬ 
mon canonical format; if it is an Ariba-compliant sup¬ 
plier, it is formatted in cXML. If the format is different, 
a B2B protocol exchange can be used to convert the 
PO to the desired format and protocol. When the re¬ 
mote supplier acknowledges the receipt of the PO, 
the state of the order at the procurement system is 
updated. Subsequently, additional messages maybe 
sent by the supplier to the procurement system to 
indicate further events, such as issuing an advance 
shipping notice. 

Marketplace connectivity for asynchronous 
processes 

As illustrated in Figure 6, IBM’s WCS MPE 4.2 pro¬ 
vides different trading mechanisms such as fixed- 
price buying, contract-based buying, RFQs, auctions, 
and exchanges. In the previous section, we described 
the punchout mechanism that can be used for re¬ 
mote supplier integration when dealing with fixed 
and contract pricing. However, the more advanced 
trading mechanisms, including RFQs, auctions, and 
exchanges, cannot be supported by the basic pun¬ 
chout mechanism. This is because the flows between 
WCS MPE and the remote suppliers for fixed and con¬ 
tract pricing are synchronous, and occur during a 
real-time session with the buyer, making them ame¬ 
nable to the on-line punchout process. RFQs, auc¬ 
tions, and exchanges involve asynchronous interac¬ 
tions between WCS MPE and the supplier. In this 
section we describe how such asynchronous processes 
are handled. We use RFQs as a typical example; sim¬ 
ilar flows and XML document interchanges can be 
used for other asynchronous trading mechanisms. 

In WCS MPE, an RFQ is a trading mechanism used 
when a buying organization attempts to obtain a spe¬ 
cial price for a purchase, or when a buying organi¬ 
zation cannot find an acceptable offering in the eMP 
aggregated catalog that meets its needs. The RFQ may 
be issued in order to obtain a special price based on 
quantity for well-defined items or for a group of 
items. The RFQ may also be issued for unique items 
based on the buyer’s description. The request is sent 
to one or more selling organizations, and these may 
submit a bid on the RFQ. The selling organizations 
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Figure 6 Trading mechanisms in WCS MPE 



respond to the RFQ and the buying organization may 
select one or more winning responses. The result of 
the RFQ process could be an order placed by the 
buyer or a contract could be created for the nego¬ 
tiated price. Figure 7 shows this process flow in 
WCS MPE. 

We now describe two different mechanisms for ex¬ 
tending the RFQ process to a distributed environ¬ 
ment. The first mechanism, which we refer to as “lo¬ 
cal RFQ,” exploits the advantages of aggregating the 
catalogs at the eMP site, while distributing only the 
RFQ process. The second mechanism, which we re¬ 
fer to as “remote RFQ,” allows buyers to connect to 
a remote WCBE at a supplier or a remote WCS MPE 
and issue an RFQ. 

For local RFQs, the catalog is hosted at the WCS MPE 
site where the buyer is registered. Figure 8 shows 
the process flow for this configuration. The config¬ 
uration includes the following parties: 

• One or more buyers 

• An eMP where the buyers are registered 

• One or more remote eMPs 

• One or more sellers registered on the remote eMP 

The flow starts with the buyer browsing the catalog 
on the eMP and creating an RFQ. The RFQ is sent as 
an xml message to the remote eMP. Upon receiving 
the RFQ, the remote eMP notifies the target sellers. 


Each seller views the RFQ and creates a response for 
it. The asynchronous responses are then sent to the 
eMP as xml messages. The buyer can check the sta¬ 
tus of the RFQ at any time. The buyer views the RFQ 
responses by logging on to the eMP, evaluates them, 
and selects a winner. Selecting a winner leads either 
to a purchase order or a negotiated contract. The 
order or the contract is then sent to the remote eMP 
or remote seller as an xml message. This solution 
has the advantages of an aggregated catalog and al¬ 
lows buyers on one eMP access to sellers on a remote 
eMP, and vice versa. It has, however, the previously 
mentioned limitations of aggregated catalogs. 

For remote RFQs, the catalog is hosted either on the 
remote eMP where the seller is registered, or on the 
remote seller’s Web site. Figure 9 shows the process 
flow for this configuration. This configuration also 
involves four parties. The flow starts with the buyer 
selecting on the local eMP a registered remote eMP 
or a remote seller. The eMP connects the buyer to 
the remote eMP site. The buyer browses the catalog 
on the remote eMP and creates an RFQ template. The 
RFQ template is then sent as an xml message to the 
eMP. The RFQ template received from the remote 
eMP is converted into RFQ by providing additional 
information. It can then be optionally submitted for 
approval. Finally it is sent to the remote eMP or re¬ 
mote seller as an xml message. The remote eMP no¬ 
tifies the target sellers. The sellers view the RFQ and 
create responses for it. The responses are then sent 
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Figure 7 RFQ process flow in WCS MPE 



to the local eMP as xml messages. The buyer views 
the RFQ responses by logging on the eMP, evaluates 
them, and selects a winner. Selecting a winner leads 
either to an order or to a negotiated contract. The 
order or the contract is then sent to the remote eMP 
or remote seller as an xml message. 

This solution overcomes the limitations of aggre¬ 
gated catalogs for such asynchronous trading mech¬ 
anisms, and allows buyers on one eMP access to sell¬ 
ers on a remote eMP, and vice versa. This comes at 
the price of losing the advantages of aggregated cat¬ 
alogs. 


Connectivity using a B2B protocol 
exchange 

In a previous section we touched on the fact that 
some suppliers participating in a private marketplace 
prefer to keep the catalog contents to themselves and 
not participate in an aggregated catalog hosted by 
the marketplace. As B2B connectivity becomes in¬ 
creasingly popular, the number of protocols for en¬ 
gaging in B2B transactions continues to grow. Given 
this growing “babelization” it is likely that businesses 
and marketplaces that need to communicate will be 
using different protocols. For this reason we have 
built B2B/M2M Protocol Exchange (M2M stands for 
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Figure 8 RFQ process flow for local RFQ 
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market-to-market), a prototype capable of convert¬ 
ing between different protocols. 

In this section we first describe how the exchange 
could be used to enable punchout between a buyer 
and a supplier using different protocols. Although 
this example is limited to punchout, the protocol ex¬ 
change can cover many other common B2B interac¬ 
tions such as shopping cart processing and order pro¬ 
cessing. 

Suppliers participating in a marketplace may have 
catalog systems already in place supporting existing 
standard or proprietary formats. These formats may 


vary from supplier to supplier. Thus, Supplier A may 
support cXML 1 punchout messages, Supplier B may 
support OCI 3 punchout messages, and Supplier C 
may support some other format. The marketplace 
punchout function must send punchout messages in 
the format and protocol that a specific supplier is 
capable of processing. The B2B protocol exchange 
is a tool that allows suppliers to interact with buyers 
whose protocols would otherwise be incompatible. 

Unlike some kinds of protocol conversions, most B2B 
protocol conversions cannot be achieved in a state¬ 
less manner, that is, in a manner in which the pro¬ 
tocol converter has no knowledge of prior events or 
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Figure 9 RFQ process flow for remote RFQ 
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message exchanges. This is because many of the pro¬ 
tocols refer to the session state or to prior messages. 
In other words, a B2B protocol involves not only mes¬ 
sage formats but also message flow and the state of 
the interchange process between business partners. 
Thus, session state management is required along 
with message format translation. 

A block diagram of a typical environment is shown 
in Figure 10. In this illustration, Buyer 1 and Sup¬ 
plier 1 use protocol A, whereas Buyer 2 and Supplier 
2 use protocol B. Information exchange between 
Buyer 1 and Supplier 2, or between Buyer 2 and Sup¬ 
plier 1, requires the use of the protocol exchange. 


The presence of the exchange is transparent to buy¬ 
ers as well as suppliers. When Buyer 1 and Supplier 
2 are interoperating, Supplier 2 appears to Buyer 1 
to be a protocol A supplier, and Buyer 1 appears to 
Supplier 2 to be a protocol B buyer. 

We now describe in some detail a punchout oper¬ 
ation such as an Ariba cXML punchout between a 
buyer and a supplier that use the same protocol. The 
data flow is illustrated in Figure 5, shown earlier; the 
numerals refer to the process steps described here. 
To purchase from a network catalog, the buyer typ¬ 
ically uses a browser to interact (1) with the procure¬ 
ment system, and through the procurement system 
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establishes a connection to a network catalog hosted 
on the supplier’s behalf. The procurement system 
thus sends a login request (2) (e.g., a cXML PunchOut- 
SetupRequest) to the supplier system. The login re¬ 
quest contains the credentials (e.g., userid/password) 
of the procurement system, a session identifier (e.g., 
(BuyerCookie) in cXML), and the postback URL, 
which is the HTTP URL at which the procurement sys¬ 
tem accepts the completed purchase requests (in step 
7, below). The supplier system authenticates the re¬ 
quest and responds (3) with the URL for accessing 
the network catalog (e.g., in a cXML PunchOutSet- 
upResponse). The procurement system then redi¬ 
rects the browser to the network catalog URL (4), 
and the buyer connects directly to the network cat¬ 
alog system (5), bypassing the procurement system. 

We have previously described in some detail the pun- 
chout operation, illustrated in Figure 5, between a 
buyer and a supplier that use the same protocol. In 
the case where the buyer and supplier use different 
protocols, they will be unable to support a punchout 
interoperation unless some mechanism such as the 
protocol exchange is used. The data flow is shown 
in Figure 11. When using a protocol exchange for 
this mapping, the procurement system is configured 
to treat the exchange as the supplier system. The ini¬ 
tial login request (2a) is sent to the exchange rather 
than the target supplier system. The processing re¬ 
quired at the exchange at this point may be fairly 
involved. Typically the protocol conversion involves 
two different authentication domains (the source 
protocol and the target protocol). The exchange must 
validate the incoming credentials and generate the 
outgoing credentials for the target protocol domain. 
In addition, the incoming request typically has an 
associated session ID (e.g., BuyerCookie), which must 
be recorded and mapped to an equivalent session 
ID in the target protocol. Also, the postback URL 
must be saved, and the URL of the exchange must 
be substituted in the outgoing message. Finally, the 
target supplier system must be identified, and the 
converted request must be passed as a new login re¬ 
quest (2b) to the target supplier system. 

When the login response (3a) is received by the ex¬ 
change, the response is converted into a protocol A 
response by the exchange and returned to the pro¬ 
curement system (3b). The procurement system re¬ 
directs (4) the browser to the network catalog site, 
and the shopping session (5) takes place directly be¬ 
tween the buyer’s browser and the network catalog 
site. At checkout time, the browser accepts the con¬ 
tents of the shopping cart in protocol B format (6), 


Figure 10 Typical B2B environment using protocol 
conversion 



Figure 11 Punchout request flow with protocol conversion 
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and sends it to the exchange (7a) rather than to the 
procurement system, due to the substitution of the 
exchange URL for the procurement system URL in 
the protocol A login response. In order to process 
the checkout, the exchange creates a new checkout 
page, with the shopping cart converted into the pro¬ 
tocol A format, and returns this page to the buyer’s 
browser (7b). The target URL of the “checkout” but- 
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ton on this page is the postback URL of the procure¬ 
ment system, which was saved during the translation 
of the login request in step (2a). The buyer is in¬ 
structed to perform a second checkout operation 
(7c), which causes the purchase request to be sub¬ 
mitted to the procurement system for approval. The 
second checkout may be hidden from the user by us¬ 
ing scripting (e.g., JavaScript**) in the HTML page 
generated by the exchange. 

This particular punchout description is one exam¬ 
ple of how the exchange flows might operate. Spe¬ 
cific protocol flows will vary in the exact details. The 
protocol exchange run time is constructed from a set 
of common protocol objects (e.g., Login, Shopping- 
Cart, Order), with plugins for specific functions of 
the various protocols. For example, the mySAP in¬ 
bound logon plugin accepts a mySAP logon request 
and converts it to an internal logon object. The cXML 
outbound logon plugin converts the logon object into 
a cXML PunchOutSetup Request. The various shop¬ 
ping cart plugins convert shopping carts in different 
protocols into a common ShoppingCart object. The 
exchange also contains code to map between cre¬ 
dential domains, e.g., from Ariba Network IDs to 
mySAP OCI userid/password. Finally there is a state 
management framework to maintain the state of a 
session and keep track of message content (such as 
the postback URL), which must be extracted from 
one message, temporarily saved, and replaced in a 
subsequent message. 

The B2B interaction between two parties is defined 
within the protocol exchange as a series of plugin 
transformations to be performed. One plugin will ac¬ 
cept a message and turn it into a common object. A 
subsequent plugin will take the object and issue it 
as a message in a different protocol. There is no im¬ 
plicit assumption, for example, that a cXML punchout 
to a supplier will result in the supplier returning the 
shopping cart in cXML format, or that a shopping cart 
returned in cXML format is to be followed by an or¬ 
der to the supplier in cXML. 

This flexibility is necessary to accommodate some 
of the interactions that are common today. As an 
example, the SAP Open Catalog Interface 3 allows the 
shopping cart to be returned in either XML or HTML, 
depending on the configuration of the buyer’s pro¬ 
curement system. Some of the private buyer and sup¬ 
plier marketplaces are implemented using combina¬ 
tions of different protocols. A supplier might expect 
an OBI logon from which it might return a cXML shop¬ 
ping cart to the purchasing system. And the subse¬ 


quent order may have to be transmitted in EDI be¬ 
cause the supplier’s EDI order processing system was 
in place running over a value-added network long 
before the supplier had implemented any B2B inter¬ 
actions over the Internet. 

It is hoped the various electronic commerce dialects 
will someday coalesce into a smaller and more con¬ 
cise set. But until then, it seems that something like 
a B2B protocol exchange will be required to bridge 
the communication gap between prospective trad¬ 
ing partners. 

Summary and conclusions 

In this paper, we have outlined various business-to- 
business connectivity protocols between procure¬ 
ment systems, private marketplaces, and suppliers, 
and have described how WCBE-based suppliers and 
private marketplaces can connect to diverse procure¬ 
ment systems, other suppliers, and external private mar¬ 
ketplaces. Specifically, we showed how WCBE-based 
suppliers and WCS MPE-based marketplaces can con¬ 
nect to buyers at procurement systems that use 
punchout, such as Ariba, 1 Commerce One, 2 and 
mySAP. 3 We then described how a WCS MPE-based 
supplier or private marketplace could originate a 
punchout process in order to connect to either an 
external supplier or another private marketplace. 

Next, we outlined the types of trading mechanisms 
that can be supported by existing punchout proto¬ 
cols and the asynchronous trading mechanisms, such 
as RFQs, that require extensions to the punchout 
mechanisms. While these mechanisms can be used 
across WCS MPE-based suppliers and private market¬ 
places, such mechanisms need to be standardized in 
order to enable them to connect to suppliers and 
marketplaces provided by other vendors. 

Finally, we described B2B/M2M Protocol Exchange, 
a tool we have implemented that can map between 
various protocols used by different procurement sys¬ 
tems. It allows a supplier using one protocol to con¬ 
nect to a procurement system or private marketplace 
that uses a different protocol. 

The WCBE-based Commerce Integrator, with sup¬ 
port for B2B procurement protocols as described in 
this paper, has been used to connect ibm.com, as a 
supplier, to enterprises using diverse procurement 
systems and to private marketplaces. Although, in 
this paper, we have focused on the external partner 
B2B protocols, a large part of the integration effort 
for suppliers is the tie-in to internal processes, such 


284 DIAS ET AL. 


IBM SYSTEMS JOURNAL, VOL 41, NO 2, 2002 


as the processes to handle purchase orders. Other 
complementary products, such as IBM’s MQSeries (to 
be renamed WebSphere MQ) and WebSphere Bus¬ 
iness Integrator, are key to completing the picture 
for end-to-end integration. 
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